The use of software applications (either by system-users controlling their management or by end-users exploiting their services) is not always a simple task. Indeed, the software applications are often so complex that it is very difficult to use them correctly in every situation. This is especially true in modern data processing systems, wherein a myriad of different software applications interact among them; the problem is further exacerbated in multi-tier environments, such as with distributed architectures, heterogeneous structures, and the like.
As a result, problems may occur during the execution of each software application because of its misuse by a (generic) user—for example, caused by a configuration error. Each problem manifests itself to the user as an undesired behavior of the software application (typically, with the return of an error message).
When this happens, the user tries to remove the undesired behavior so as to recover the correct operation of the software application. However, this recovery process is very difficult. Indeed, the user should at first trace the undesired behavior to the cause of the corresponding problem; this is quite complex, since the same undesired behavior may often be due to different problems. It is then necessary to understand how to correct the problem, so as to eliminate the undesired behavior of the software application.
Some tools aimed at facilitating the above-mentioned recovery process are available.
Particularly, the software application is almost always provided with manuals that may be consulted by the user. The manuals typically end with a problem-solution section. This section lists the known undesired behaviors of the software application (referred to as symptoms); for each symptom, there is indicated the possible causes, together with their suggested corrections.
As a further improvement, it has also been proposed to associate a symptom database with the software application; as above, the symptom database provides a list of the known symptoms of the software application with their causes and corrections. The information in the symptom database is arranged in a predefined format, so as to facilitate its use; moreover, this allows exploiting different service tools that can access the symptom database during the recovery process. For example, the “IBM Support Assistant (ISA)” is a commercial plug-in for every software application, which plug-in provides a standard interface to the corresponding symptom database.
The population of the symptom database requires logging any possible undesired behavior of the software application with all its causes and corrections. This is a substantial manual process, which is mainly based on an investigation process requiring a heavy human intervention; as a consequence, the process is tedious, time consuming and error prone.
The process of populating the symptom database is then often left as the last one in the development of the software application. Therefore, it is not uncommon to have software applications that are released with a very poor or even empty symptom database—which is then populated over time as undesired behaviors of the software application are reported by the users.
However, all of the above has a detrimental impact on the usability of the software application.